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Ps 


SCOPE AND INTENT. 


THIS OOCUMENT IS ROT INTENDED TO OFYSCUSS THE REASONS FOR GOING 
TO "MIRAM". THAT CAN GE JUSTIFIFD 2¥Y SIMPLY EXTRAPOLATING SPERRY 
UNIVAC'S LONG RANGE SYSTEM SCFITWARE PLANS,» FROM THE OS/3. RELEASE 
7.0 ANNOUNCEMENTS. ALL THF NEW OPERATING SYSTEM COMPONENTS REVOLVE 
TOTALLY AROUND A “CENTSALIZED DATA MANAGEMENT” INTERFACE WHICH IS 
TOTALLY MIRAM¥ SASELe ALL THE New SYSTCM DATA MANAGEMENT 
ENHANCEMENTS, SUCH AS MOVING TOWARD AN OPFRATING SYSTEM ENVIRONMENT 
THAT wWItt SJPPORT SHARED UPDATE OF UNE FILE BY TWO INCE PENDANT 
JO8S, TS AASED ON MIRAMe THE ORIGINAL DATA MANAGEMENT ACCESS 
METHOOS ARE SIMPLY "SUPPCRIER™ IN RELEASE 7e%, AS THEY EXISTED IN 
KELEASE Gele THLREFORE, THCSE USERS bkHO FNTENG TO PROGPESS WITH 
OS/3 IN THE FUTURE, FUST SEGIN TO MUVE TUMARD *T KAM. THIS NOCUMENT, 
THEN, IS TNTE''NEG SOLELY TC POINT GUT SOsF CONSIOFCATIONS THAT ONE 
SAQULD TAKE INTO ACCOUNT WHILE ATTEMFYTT AG TO MIKE THAT MOVE. 


COCUMENT: TUUA -F8C REV:1.9 SECTIONS]. 
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20. 


wel. 


WHAT IS MIRAM. 


SENERAL DESIGN. 


“"MULTI-INDO¥YED RANDOM ACCESS METHOL™ <(MIRAM)D IS ACTUALLY A 
SLIGHT MISNOMEP, AS THE MIFAM DATA MANAGEMENT STRUCTURE ENCOMPASSES 
MUCH MORE THAN JUST “INDEXED™ FILE STP UCTURESe MIRAM FILES CAN 
EXIST EN TwO PPIMARY STATES, INCEXEO OR NON-INDEXEO CSOMETIMES 
REFEKEC TO &S CONSECUTIVE). I REFER TO THESE AS “PRIMARY” STATES 
DUE TO THE FACT THAT THERE ARE ACTUALLY A NUMPER OF “HYBRID” 
IMPLEMENTATIONS OF MIRAM, INVOLVING POSSIBLY COMPLEX COMBINATIONS 
OF BOTH INDEXE™ AND AON-INDEKED DATA RECGRIS WITHIN THE SAME FILE. 
THESE SFECIAL STATES wItt NOT BE DISCUSSED IN THIS PAPER AS THEY 
ARE APPLICABLE ONLY TO A SMALL SEGMENT OF USERS AND, IN: FACT, CAN 
WOT EVEN 38E CREATED CXCEPT AT THE ASSEMBLER “MACRO™ LEVEL. 


NON-INCE XE (CONSECUTIVE) MIRAMe 


NON-IADE XE 9 MI RAM FILES FMAY MOST SIMPLY BE COMPAREC TO 
CONVENTIONAL "SAM™ FILES. HOWEVER, THEY &LSO PROVIDE THE SASIS FOR 
THE “DIRECT FUNCTIGNS THAT WERE TRADITIONALLY PEPFORMED Sy "NAM™, 
THERE IS NQ DISTINCTION MADC WITHIN FILE DESCRIPTOR INFORMATION IN 
A DISK PACK*S VTOC, BETWEEN MYRAM “SEQUENTIAL” AND “"OIRECT”™ FILES. 
THEY ARE FULLY INTE RCHANGARLE WITH THF METHOL CF PROCESSING REING 
DETERMINED SOLFLY 3Y THE FILE OcFINITIGw IN A USING PPOGRAM. 


INDEXED MIPAMe 


TREE INSEXES MIFAM FILLS ARE, OF COURSE, INTENDED TO FRO VIDE 
THOSE FUNCTICNS FORMERLY FROVIDED RY “IS&™" FILES. HOW" VER,» 
NUMEROUS CHAPAC TERISTICS DISTINGUTSH THE™ FROM THEIR ISAM 
PREDECESSORS. 


INDEXED MIRAM FILES ARF "TWO PARTITION" FILESe UNLIKE ISAM, THE 
FIFST PARTITION CONTAINS THE DATA KECGRDS, AND THE SECOND ONE 
CONTAINS THE INDEX STRUCTUREs THERE CAN PE FROM ONE TO FIVE 
SEPARATE INDEX£S INTO A GIVEN RECORD. FACH OF THE FIVE INDEXES IS 
GEFINCE WITH FOUR “INDEX CHARACTERISTICS". WO OF THESE ARE 
OBVIGUSLY "KEY LENGTR”™ ANO "KEY LOCATION“. THE OTHER TWO DEAL WITH 
HOW A PARTICULAR INDEX MAY BF PROCESSEL. IT MAY PE DEFINED AS 
ALLOSING OP NOT ALLOWING DUPLICATE KEYS. TY MAY ALSO BE DEFINED AS 
ALLOWING CR NOT ALLOWING A KEY TO BF CRANGED. WHEN A KEY IS 
CHANGED, MIRAM DATA MANAGEMENT AUTOMATICALLY CHANGES THE INDEX 
STRUCTURE SO 4S TO PLACE THE PECORE IN LTS NEW SEQUENCE WITHIN THAT 
KEY. 


ONE OF THE 4OST IMPORTANT OIFFERENCES PE TWEEN "ISAM™ AND “MIRAM® 
1S ThE INDEX DESITGNe SAM FILES ONLY INCTEXEGC A SMALL PORTION, OF 
ONLY THE ORICINALLY LOADED RECORDS. IN SN INDEXED MIRAM FILEs ALL 
FECORDS HAVE AN INDEX ENTRY WHICH PUINTS TO THEM, REGARDLESS OF 


DOCUMENT: TUUA-Fed Pevste€ SECTION s2e3-6 
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WHETHER THEY ARE FART CF THE ORIGINALLY LOADED FILE, OR WHETHER 
THEY ARE ACDED LATE Re THIS ONE VARIATICN REQUIRES A USER YO THINK 
OF MIRAM IN A TOTALLY DIFFERENT FASHION, IMPACTING EVERYTHING FROM 


RECOVERY, TO PERFORMANCE. THESE TOPICS WILt ALL bE COVERED. 


~ DURING AN INCE XED MIRAM FILE LOAD, A MULTI-LEVEL, 
TREE-STRUCTURED INDEX IS CREATEDe THE “TOP-LEVEL” INDEX IS aAtwaysS 
CREATED $0 AS TO -ALLOw FOR “"HARNWKARF SFA RCHES™. ALL OTHER LEVELS 
ARE SEARCHED VIA A SGFIWARE ALGGRITHMe CURING THE LOAD PROCESS» THE 
INCEX SLOCKS ARE NEVER FILLEO COMPLETELY, BUT INSTEAD, ARE ONLY 
FILLED TO THE “THREE-QUARTER™ POINT. THE ACTUAL DATA RECORPS OF THE 
FILE ARE CONTIGUOUSLY PLACEO INTO THE DATA PARTITION SEQUENTIALLY, 
IN TRE SAME ORDER IN WHICH THEY ARE FRESUNTED TO MIRAM. 


THE CATA AEA CONTAINS NO “OVERFLOW” AREA*e INSTEAD, NEWLY ADCED 
RECORDS ARF PLACED INTO THE GATA AREA, JUST AS RECORDS WERE DURING 
THE FILE LOAD. THEY ARE SIMPLY PLACED SEQUENTIALLY INTO THE FILE 
IMMELIATELY 32HIND THE ORIGINALLY LOADED 22 CORFS. IF THE DATA AREA 
THAT WAS OFIGTIYALLY ALLOCATEL IS EVER FILLED UP, THEN THE FILE wWILt 
AUTOMATICALLY FXTEND AND CONTIAUE TO SE FILLED IN THIS WAY. 


ThE INTEX IS CONTINUALLY MOPIFIED NURING "ADO" FUNCTIONS TO 
REFLECT THE CURRENT RECORD CONTZENTSe INDEX INTRIES ARE INSERTED IN 
THEIR PROPER PLACE WITHIN INDEX ELCCKS, UNTIL A GIVEN RLOCK HAS 
BEEN COMFLETELY FILLED. WHEN THIS GCCUnS, MIFAM DATA MANAGEMENT 
MAKES A SYSTEM TRANSIENT CALL WHICH "SPLITS" THAT INDEX BLOCK IN 
HALF, THEREBY MAKING ROOM FOR MORF ERXTFIESe TRE INDEX “MANAGEMENT 
FOUTINE, CLIKT THOSE THAT MANAGE THE ACTUAL DATA RECORDS, PLACE THE 
NEW INDEX RLOCXS AT THE GACK OF THE INDEX. IT CAN ALSO CALL ON 0S/3 
EXTEND PROCESSING 10 AQUTRE MOKE PHYSICAL SPACE IN WHICH TO PLACE 
AN INDEX BLOCK. 


FECORD CONTROL BYTES (FCe°S). 


ASISE FROM “ULTIPLE INDEXES, ANOTHE®? MAJOR INOVATION IN MIRAM IS 
THE RECCRO CONTROL FfYTE (ROR). THIS 15 AN OFTIONAL ONE RYTE AREA 
@HTCh, IF PRESENT, WILL IMMELIATELY PRECLET aA TATA RECORD. IT IS 
KEVEAR MADE AVATLAPLE TO A USFR®S FROGRAM, PUT INSTEAD, IS 
COMPLETELY MATNTAINEC BY DETA MANAGEMENT. ITS PRIMARY PURPOSE IS TO 
PROVIDE FOR THE “DELETE” FACILITY WITHIN MIRAMe 


MIRAM DELETE PROCESSING OGES NOT CAUSE A KECORD TO FE PHYSICALLY 
PUSGEDe INSTCAO, THE KECORD IS FLAGLED SuChH THAT ALi FUTURE 
ACCESSES TO THE FILE WILL AUTOMATICALLY “BYPASS” CR “IGNORE™ THE 
RECOKD. THE VECORD IS NEVER TRULY REHUVED UNTIL SUCH TIME AS THE 
FILE UNDERGOES SOME TYPE OF “USER-INITIATEDS™ REGRGANI ZATION. 


TY IS IMPORTANT TO RECOGNIZE THAT THIS FCRM OF DELETE IS MUCH 
CIFFERENT THAN THE HEX *FF® OCCLETE CODE IMPLEMENTED WITHIN IMS/902 
THIS "FCA OELE TE FACILITY INVOLVES AQ USF COTE HHAT-SO-EVERe ONCE 
A RECORD IS DELETED, NO OTHER PROGPAM FCCESSING THE FILE wit BE 
ASLE TO FRETRIF VG IT. 


RCB USE IS DETERMINED SOLELY AT FILE CREATICN TIME. THIS MAY BE 


OOCUMENT: TUUA-FeO REV21.0 SECTIONs2e4, 
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ITH EITHER A "DIF" OPTION OR VIA JCLy Bu T ONCE SET, ALL SUBSEQUENT. 
USING PROGRAMS WILL FROCESS THE FILE ACCORDINGLY, REGARDLESS OF 
THEIR CTF OR JCL SETTINGS. : 


DOCUMENT: TUUA-FED PEV31.6 SECTIONs2 04%. 
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WHERE COES IRAM FIT IN ?. 


TKDE XED RANDOM ACCESS METHOD CIRAM) IL SIMPLY THE PREDECESSOR TO 
MIFAM, BUT 1T ¥S A DIFFERENT ACCESS FPETHCD AKD IT DOES. REQUIRE A 
TOTALLY OIFFERENT LATA MANAGEMENT MODULE AND DIF TO SUPPORT IT. 
EECAUSE CERTAIN OS/3 COMPONENTS wILL SUPPOFT IFAM, BUT WILL NOT YET 
SUPPORT S“TRA%, IT IS CRITICAL TO RECOGNIZE THF CIFFERENCES BETWEEN 
THE TWO. 


IfAM INDEX AND CATA APEAS ARE MAINTAINED ESSEATIALLY JUST LIKE 
THOSE IN MIRA, HOWEVER, TRAN FILES CAN GNLY HAVE CNE INDEX, WHERE 
MIRAM FILES COULD HAVE UP TO FIVFe SECUNTLY, TRAM INDEXES WILL NOT 
SUFPOPRT CHANGES TO KLYS OR OQUPLICATE KEYS. AND LASTLY, IRAM FILES 
CAN NEVER HAVE RCOS8*S. 


ANY FILE CREATED FY TRAM OATA MANAGEMLNT CAN PE PROCESSED BY 
FROGRAMS WHICH USE MI1RAM DATA MANAGCMENT &2°D MIRAM “DTF™Se HOWEVER, 
TRAM DATA MANAGEMENT CAN NCT PFOCFSS ALL FIL®ES CREATED BY BIRAM 
COLE. OCNLY THOSE MIRAM FILES WHICH AFE SAT? TO BE "IRAM COMPATIBLE” 
CAN EF PROCESSED BY IRAM DATA MANAGEMENT. TO RE IRAM COMPATIBLE, 
THE PIRAM FILE MUST: 


= NOT “AWD MGRE THAN ONE INDEX, 


= NOT AAVE THE INUEXe IF ANY», DFFINED AS ALLOWING EY THER 
KEY CHANGES OR OUFLICATE KEYS, 


= ANDO, CAN NOT HAVE THE FCR FFATUSF INVOKED. 


DOCUMENT ss TUUA -F&O REV 21.0 SECTIONS 36 
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SUPPCRT OF MIRAM. 


LANGUAGES. 


ALL THF TALK OF IRAM CCMFATIEILITY IS SO IMPORTANT OUE, 
FRIMARILY, TO THE MIXED SUPPORT OF MIRAM FAVATLABLE IN OS/3 6eX~ 
FIRST, THE SUPPORT WItt cE SUMMARY 2tD, THEN THE CONSIDERATIONS 
RESULTING FROM THIS SUPPORT WILL RE DISCUSSED. 


= FPG-TIs THIS StIPPOFTS GNLY IRAM, OR “IPAM COMPATIBLE” 
MIRAY FILESe Ih ADOITICGNs RPG -IT PROFRAMS CAN ETTHER- BE 
COMPILED WITH ALL CONVENTIONAL DATA MANAGEMENT (SAM, DAMy 
ISA“%), OR ONLY IFAM, THERE CAN CIIRRENTLY BE NO MIXTURE OF 
THE TWO 


= T4MS/90: TRAM Ok “TRAM COMFATIELE™ ONLY, BUT ONLY FOR 
INDE YSD OR NIRLCY PROCESSING. 


& TIP/332 FULL MLRAM SUPPOFTe 
- = ANS &3 fOBLLE NO SUPPOKTe 


= ANS 74 COBOL: FULL MIWAM JSUPPORT (EXCEPT FOR ONE 
OVERSTSHT SELATED TO MIRAM “THODY LUFFERS™.) 


- FORTPAN JVi FULL “I RAM SUPEORT. 
- CATA UTILITY: FULL MIRA SUPPORT. 
- SORT/SORT3: IRAM OR "IRAM COMPATIBLE” ONLY. 


- ASSEMBLER: FULL MIRAM SUPPORT. CHOWF WER, NONE OF THE 1/0 
MACROS AGE DOCUMENTEL. 


TRE ONE ASPECT OF THE CURRENT MIROM IMPLEMENTATION WHICH CAUSES 
THE MOST CCNFUSION IS THE FACT THAT hO IHS/9C SUPPORT YET EXISTS» 
EXCEFT IN IPSM COMPATARLE MOUF. THIS MEANS THAT, FOR ONE, NO 
MULTIPLY INOEXFO FILES CAN Gl USES OK-LIWh. THIS IS A HARN AND FAST 
LIMITATIONe YOU CAN NOT CIRCUMVENT IT BY EXPECTING TO RE ABLE TO 
CEFIKE T8O, SINGLE IADEXtO IRAM FILES IN IMS/90 TO HANDLE ONE 
MULTiPLY INDEvYtu ARAM FILE. IT JUST WILL NOT WORK. (SUPPCRT FOR 
FULTIPLE TNOEXES IS CCRECULED Fo COME IN SOME FUTUPE FELEASE, BUT 
WOT IN RELEAST Fe de AS NOTED ABOVE, HOaL VER, TIF/3C CAN CURVE NTLY 
PROCESS MULTI-INCEXES FILES AS WELL AS MITAM CUTPUT FILES, IN AN 
ON-LINE ENVIRINAE NT. 


DOCUMENT sTUUA-FLO REVsf.u SECTION SGe le 
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FILE CREATION COMPATIBILITY CONSINE RATIONS. 


“We2ele RCB SELECTION. 


DUE TO THE VARTOUS MIXTURES OF MIRAM/ITOEAM SUPPORT ACROSS SYSTEM 
OMFONENTS, USFRS MAY BE FORCED YO RUN THEIR MIRAM FYLES IN TOTAL 
IRAM COMPATIBLTTY MOLE. THIS MEANS, ACTOE FROM USING NO MORE THAN 
ONE INOEX, THAT ALL FILES MUST BE CREATED wiTHOUT RCB*Se AS STATED 
EARLIER, THIS MUST BE DONE AT CREATION TIME.’ FOR ANS 74 COBOL, RCB 
CONTROL YS HANCDLEO SOLELY BY JCLe COBGCL WILL AUTOMATICALLY PLACE 
RCB°S ON THE FILE UALESS THEY ARE SUPPRESSED ON THE “4/ DD" 
STATCMENTe THIS 3S CONE BY SPECIFYING “"ACR=ONO". REMEMBER, THIS HAS 
TO bE CONE wHTN THE FILE 1S LOADED. 


H$e2e2e INfEX BUFFER SIZES. 


ANOTHER CO4PATIRILITY PFOKLEM IN MYPAM REVOLVES AROUND “INDEX 
BUFFER SI7E". THIS ONLY OCCURS WHEN DEALING WITH INDEXED FILES. 
WHEN A USER CREATES AN INOEXED MIRBM/IFAM FILE, KE MUST SPECIFY AT 
LEAST ONE, 256 BYTE AREF, BUT POSST2LY “ORE, TO BE USED BY MIRAM 
INDEX PROCESSING. THE CATCH IS THAT ALL FUTURE PPOGRAMS WHICH 
REFERENCE THE FILE MUST SPECIFY THE EXACT SAME BUFFER SIZFe FAILURE 
TO ACHERE TO THIS RESULTS IN A “DMI7" EFROR AT GPEN TIKEe OF 
COURSE, TEE LARGER THE BUFFER, JHE MCRE EFFICIENTLY MIRAM CAN 
OPERATE. RUT THERE IS A SECOND CATCH. WHEN TREY IMPLEMENTED ANS 78 
CDVROL, THCY FORGOT TO PROVIDE FOR USER SELECTAFLE INDEX SIZES (THIS 
IS COMING TN SFLEASE FeG}. CORCL ALWAYS COMPILES WITH ROOM FOR ONLY 
ONE 256 BYTE APEA’ THUS, THOSE FILES WHICH MUST BF PROCESSED BY ANS 
74 COBOL MUST FE CREATED WITH THIS Ih MIND. (TsEe, OQNLY ONE INCEX 
BUFFER.) 


4.223. MULTI -VOLUME MOUNT INDICATOR. 


AKY RKONTINTVEXEOD sCONSCCUTIVE) MIRAM FILE WHICH WILL BE USED FOR 
DIFECT PROCESSING MUST ALWAYS BE CREATED wITH THE “MULTI-VOLUME 
MOUNT INDICATOR’ SET. THE ONLY PLACE THAT A USER REALLY HAS TO 
WORRY AEOUT THIS IS AT THE ASSEMFLER LEVEL, OR WITH “DATA 
UTILITIES". IN THE CASE OF UATA UTILITIES, YHERE IS A “V¥™ 
PISITIONAL PARAMETER WHICH SHOULD ALWAYS BF COPED. FAILURE TO CODE 
TT WILt RESULT IN A “DM EPROR AT CPEN TIME. ° 


INCE A PARTITION SIZING. 


AS WAS STATED CARLIER, MIFAM YINOFYIRG IS IMPLEMENTED VIA A TWO 
PARTITION FILFe OUE TO THE FACY THAT ALL RECORES ARE INDEXED, THE 
INCEX AREA OCCUPIES SIGNIFICANTLY MORE SFACE OUT OF THE TOTAL FILE» 
THAN IT CIO IN AN ISAM ENVIRONMERTe IN AUDITION, THIS ARRANGEMENT 
RESULTS ITN LARGE VARIATIONS, FROM GNE FYLi TO ANOTHER, AS TO WHAT 
PERCENTAGE OF TOTAL FILE SPACE A MIRAM INODFX SHCULD OCCUPY. WHEN 


DOCUMENT: TULA-Fan REVs2eL , SECTIONS% «36 
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CREATI®G A NFWy INCEXED MIRKAM FILE. MIRAM w¥Li AUTOMATICALLY TAKE 
INTO ACCOUNT INDEX LENGTH AND RECORG SIZE TO COME UP WITH AN 
CPTIMUM PERCENTAGE TO BE ALLOCATED 10 THE INDEX. THE CATCH HERE ITS 
THAT, ALTHOUGH YOU WOULT (ECYPECT OTHERVISE, THIS OPTIMIZATION 
FUNCTION YS NOT DONC BY DEFAULT. THE OF FAULT IS FOP MIRAM TO ALWAYS 
ASSIGN ONLY ONE PERCENT OF THE FILE SPACE TO TKE INDEXe YOU MUST 
INCLUDE THE “4/4 OD" PARAMETER “SIT7L=4UTO" IN ORDER TO GET THE 
COTIMNUM ALLOCATIONS 


RECOVERY. 


H§e4el. WHAT IS PECOVERY 7? 


RECOVERY CAPABILITY IS CNL OF TRE MOST IMFORTANT OF THE OF TIONAL 
FEATURES IMPLUMENTEC IN MTRAMee HOWEDVch, DUE TO ITS POTENTIAL FOR 
INCREASING 179 PROCLSSING OVERHEAD, IT IS CRITICAL THAT IY ONLY BE 
USF D WKEN NEEDS Oe 


TrE RECOVERY OPTION IS EEARED TOWARN ONLY ONE THING, TO ENSURE 
FILE INTEGRITY AT TIMES WHEN RECORDS xHaVE HEEN ADDED TO THE FILEs 
ANE JHE FILE DOES NOT CET PROPFRLY CLOSEG. THIS COULD HAPPEN SUE TO 
SUCH THIAGS AS POWER FAILUSES OR HPR STOPS. 


RECOVERY CAN BRE APPLILE FO GOTH SCOUPNTIAL/RANDOM FILES 
(CONSECUTIVE) AND INDE XE O FILES. IN THE CASE OF CONST CUTIVE FILES» 
RECOVERY WILL SIMPLY ENSURF THAT ONCE THE ENC -OF-“FILE LCCATION 
BEGINS TO CHANGE» AFTER A FILE 18 GPEMEG, TRAT THE NEW ENC -OF-FILE 
LOCATION WILL "OT RE LOST, SHOULL A SYSTEM FAILURE OCCUR. FAYLURE 
TO FAVE RECOVERY IN EFFECT tb 9ULG ALY CAUSE YOU TO LOSE THOSE 
RECORDS ADDEL SINCE THE “OFEN, SUT ¥OILE NOT CAUSE THE FILE TO BE 
PFENOEREO UNUSABLE} THIS SAME PROTECTICN 15 PROVIDED FOR INDEXED 
MIRAM FILES, 45 AELL AS PPOTECTIUN AGAINST COMPOMISED INDEXES (MORE 
ON THIS LATER). 


EACH TIME THE “COC NL-OF-FILE™ SETTING FUR A FILE CHANGES, MIRAM 
ROTES THE NEw END-OF-FILE SCTTING INVG THE FIRST SECTOR CF THE FILE 
(IT 1S RESERVED SPECIFICALLY FOR THIS AT FTLE CREATION TIMED. IF 
SYSTEM FATLUTE OCCURS, THE oJESCREPENCY EOE TWEEN THIS “RECOVERY 
SECTCR™ ANC THE vTOC IS 2FCCGMNIZED THE NEXT TIME THE FILE IS 
OPENED. THE FND-OF-FILE wGTEO IN THE SECTOR IS THEN USED TO 
OVERKTOc THE INE SHISN LN THE VICCe : 


AS YOU MIGHT ILAAGINE, THIS IMPLItS ONE ADLITIONAL WEITE, FOR 
EACH USER FECORD WRITTEN. RECAUSE THE RECOVERY FUNCTION IS HANDLED 
bY A “TOANSTENT CALL", THE PE TS ACTUALLY “CRE CVETHEAN INVOLVED 
THAN JUST THE TO TO THE PF CUVERY SECTCR. IT IS FOR THIS PEASON 
THAT RECOVERY SHOULD NOY BE APPLYFO LOOSELY FO ALL USER FILES. 
THOSE FILTS US®D IN SUCH A MANKRE® THAT SYSTEM CRASHES CAN BE 
CIRCUMVENTED FY COMPLETE RERUNS, FROM AN ORIGINAL VERSION OF THE 
FILE, SHOULD NOT 3E RECONVEFY PROTECTED. “OST RCOVERY POOTECTION 
WILL ©&F APPLIED TC ON-LINE FILES. CURTENTLY IMS/9F SUSPORTS NO 


COCUMENT sTUUA -F &L PEV21-0 SECTION SG Hole 
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- OUTPUT IRAM FILES Aw RLLATIVE TRAP FILLS CAN NOT FE EXTENDED (AS | 
ra COULD DAM FILES), HINCE, INDEXED IRAM ON-LINE FILES ARE THE ONLY 
T ot ONES THAT REALLY NEED THE RECOVERY OPTION SETe NOTE AGAIN, HOWEVER, 
F THAT TIP/30 DOES SUPPORT TFAM/MIXAM OUTPUT FILFS, AND THAT RECOVERY 
CAN bC USED ON THEM 10 ENSURE THAT THE LAT-OF-FILE POINTER IS NEVER 
LOST, &S T© CURRENTLY THE CASE WHEN USING “SA GUTPUT FILES. 


EARLIER IT WAS STATED THAT MIKAM RECUVERY PROTECTS AGAINST A 
COMPFOMISED INDEX AREA ITS INTENT TS REALLY NOT 10 PREVENT THEM 
FROM SFING COMPROMISED, INSTEAD, IT ENSURES THAT ONCE COMPROMISE Ds 
THE USFR IS MADE AWARE OF THAT FACT SO THAT FURTKER MEASURES C8N BE 
TAKEN TO REPAT®?® THE FILE. WHAT MIRAM NOLTS ITS TURN A FLAG IN THE 
RECOVESY SECTIR, ON VCUST REFORE INCEX MODIFICATION BEGINS, AND THEN 
CFF AGAIN WHEN INDEX MOOI FICATION FS COMPLE TE (HCRE 1/0 OVERHEAL TC 
BE AWAKE CE). THIS WeUULD TAKE PLACE LACH TIME A NEW FECORD IS ADDED 
TO TRE FILE. THUS WHEN AN INDEXEL FILE 15 OPENFEO, TF THE FLAG IS 
ON, MIRAY KNIWS THAT THRE SYSTEM MUST HAVE CRASHED WHILE IN THE 
PROCESS OF MODIFYING THE TNOEX. JN SUCH A CASE, A “DM66" ERROR IS 
1SSsutO PY THE OPEN FUNCTION, ANC THE FILE WILL NOT BE OPENED FOR 
THE KECUESTING PROG RAMe 


ANYTIME A “DM66" OCCURS, A USER HUST IMMECIATELY READ THE FILE 
“CONSECUTIVELY, IGNORING THE INUEXESe ThIS WILL RETRIEVE ALL THE 
DATA RECORDS IN THE FILE, INCLUDING THUSE AONED JUST PRIOR TO THE 
CRASte. THOSE “UST THEN BF SORTED ON THE KEY FIELD ANDO THEN 
RELOADED, SO THAT TRE IKSEX STRUCTUFE WiLL FE RERUIL Te THE EASIEST 
wAy 10 DO THIS IS FO FEEG THE FILE DIRECTLY INTO THE SORT, AS IT 
& ALWAYS READS IfAM FILES CONSECUTIVELY, AND DOES NOT USE THE INDEX. 


IF TS ALSO IMPORTANT TO CONSIDER KRERL, WHAT wILtl HAPPEN TO A 
SYSTEM THAT CRASHES, WITH TRAM FILES whICH HAVE HAD PECORDS ADDED 
TO THEM, BUT NC NOT HAVE RECOVERY SETe FISSTLY» THE INDEX STRUCTURE 
WOULD ALWAYS 3€ COMPHOMISEP. THIS MOULN LE DUE TO THE FACT THAT THE 
NEW INDEX ENTRIES AOCED STNCE "“OFEN™ TiMe, wWOULC BE POINTING TO 
RECORDS WHICH NOW RESIDE PAST THE ENG CF FILE LOCATION NOTED IN THE 
VTOC.e. ATTEMPTING TO PROCESS THE FILE VIA TTS FNDEXES WOULD RESULT 
IN THE “INVALID JE, EXCELOS FILE LIMLTS™ SATA MANAGEMENT ERRORS 
THUS, TRE SFR FS FORCES Tu JMMLUTATELY READ THE FILE 
CONSECUTIVELY, ANC nELOAD IT, LOSTNG ALL FECOTOS ADCEL OURING ThIS 
LAST SESSTON. SUTe IF HE FAILS Tu OC THiSs &NT ACCIDENTLY BRINGS 
THE SYSTEM BATK UP, GRAM WOULD BEGIN ATCING NEW RECORDS TO THE FILE 
ANC WOULD FVENTUALLY "PuSH™ THE ENF GF FILE FOYNTER PAST TPE POINT 
WHERE TRE “LOST SECORDS BAD FEEN ADO De THE “FILE LIMITS” ERROR 
WOULD GO AWAY, BUT NC@d ALL THOSE INOEX ENTITIES ACDED PRIOR TO THE 
CRAStF WOULD FE POINTING TO KECORRS, YHICH wERE ADDED AFTER THE 
SYSTEM WAS BROUGHT SACK UPe THE JHDEX ANE FAFA RECORD KEYS. WOULD 
OBVIOUSLY NOT MATCH, RESULTING IN MCRE FUN ANG EXCITEMENT OURING 
SOME LATER BATCH RUNS 


COCUMENTsTHUUA -F 53 REvsled SECTIONS4 Hele 
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— eGe2e =O RECOVERY UCL 


In OROFR TO HAVE A FILE CREATED WITH RECOVERY: “RE CV=YES™” MUST 
HE SFECIFIEO ON THE *// UD” STATEMENT WHEN THE FILE IS CREATED. IT 
CAN NOT S&F ADDED LATER WITHOUT RELOADING THE FILEs 


DUE TO THE FACT TRAT MIRAM WILL NOT OFFN A FILE WHOSE INDEX IS 
COMPROMISTO, A VARIATION OF THE “REC W™ KEYSORD EXISTS WHICH WILL 
OVERRIDE THE “O466™" ERROR WHICH IS NORMALLY ISSUED WHEN AN OPEN IS 
ATTEMPTEEL TO THE GAD FILE. THIS SHOULEG CNLY BE USED IN THGSE JOB 
STREAMS INTENDED FOR SYSTEM CRASH RECOVERY, FOR EXAMPLE IN A DEVICE 
ASSIGNMENT SET FOR A SORT INPUT FILE>s IN THESE CASES, YOU MUST CODE 
“RECVISFCE” ON THE “// DO” STATEMENT. 


VAPIA@LE SECTOR SIZE (VSEC). 


IN MIRAM*®S FORERUNNER, IRAM, ONE OF ITS MOST ATTRACTIVE 
CHARACTERISTICS, FKOM A PROGRAMMING STENDPOINT, WAS THE 
INTRODUCTION OF THE SECTURED DATA MANAGEMENT EPPROACH. WHAT THIS 
MEANT WAS THAT ON SECTORIZTFO DISKS (64913€°S AND 16°S) THE SECTOR, OP 
256€ GBYTES, WAS THE ACTUAL PHYSICAL BLOCK STZE- THUS, ALL IPAM FILES 
HAC THE EXACT SAME BLOCK SIZE. RECORLS WERE STORED CONTIGUOUSLY 
WITHIN THE FILE,» WITH NO REGARD FOR WRHRERE THE SE PHYSICAL BLOCKS 
STARTEL OF ENDED. RECOFOS SPANKER SECTORS, TFACKS, AND CYLINDERS 
THE VALUE THAT YOU CODEL In USER SROGREMS AS SLOCK SIZE RAS 
-REALLY~- USED TO SET THE PROGRAM*®S I/0 BUFFEE STZE. IT WAS ALWAYS 
ROUNCED G?® TO SOME MULTIPLE OF 256 RYTESe USER*S COULD SPECIFY 
LARGE OR SMALL BLOCK f€PUFFER) SIZES FOX THE SAME FILE DEPENDING ON 
THF APPLICATION INVOLVFO. TRAM BOULUD SIMPLY FEFUO AS MANY SECTORS, 
IN GNE TsPUT OPERATION, 4S wuUttLD FIT 8% THAT PARTICULAS BUFFER. 
we HAT THIS MEANT WAS THAT TEE OLU CUNCE PI OF BLOCK SIZES RE CAME 
MEANINGLESS «© THE ONLY LIMITATION CEALT WITH SECORD STZ7Ee A USERTS 
BUFFER HAD TO YE LARGE ENCUGH Tu HOLE THE NUMBFR OF SECTOPS WHICH 
ONC RECORD COULD POSSTGBLY SFANs FOR EXAMPLE, 4&8 RECORD OF 258 BYTES 
COULL, AT SOM™ PUINT IN THE FILO, SPAN THREE SECTORS. THUS ¢ THE 
MINIMUM PUFFFR SIZE FOR FILES OF THIS wECOROD SIZE wOULD ALWAYS BE 
768 EYTES (3 X 256). ALL THi COMPILERS wikF COOTER TO ACCOUNT FOR 
THESE MINIMUMS, REGARDLESS OF WHAT A USL R MIGHT CODE. FOR EXAMPLE, 
AN RFG-II USER WHO CODED A BLOCK SIZE CF 258 FOR THE ABOVE RECORD 
WOULT HAVE REALLY GCITEN A 7208 BYTE KUFFLRe 


THIS WAS A VERY KEEN CONCEPT IN THECRYe IT HAD WORKEO GREAT FOR 
IBM°S SYSTEM/3, WHY NOT UNDLw OS/3 7? IT wAS NICE FOR THE SECTORIZED 
CISK USERS (6416 AND le USERS). THE PROBLEMS AROSE WITH THE 
NON@SEC TORI 2E9 SELECTOR CISKS, ESPECIALLY VHE 8439/33 DISKS. TO 
CONFORM wITH DF SIGN CONSTPAINTS, TFAM WROTE PHYSICAL 3LOCK SIZES OF 
256 BYTES TO ALL SELECTOR DISKS, JUST AS ITT AIO FOR THE SECTORIZED 
OISKS.e THIS WOFKED JUST FIRE. HOW VER, GUE TO YHE FACT THAT SMALL 
FLOCK SITES, LIKE 256 &YTES, RESULT IN LARGER NUMBERS OF 
“INTER-RECCRD GAPS", TRAM FORKMATTES LISm SPACE WASTEL APPROXIMATELY 
92 TO 452 OF THE TOTAL CAPACITY AVAILAGLF ON THF Sa 30/33 DISK 
CRIVE. TRIS MADE SELECTOR FISK OWNERS VvViRY URHAPPY, To SAY THE 
LEAST. 
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TRE “SOLUTION” TO THIS, INTRODUCES WITH MIP AM AND RETROFITTED TO 
IQAM IN RELEASE 60M, WAS “VARIABLE SECTOK” SUPPORT. THE IDEA, WHICH 
IS NOT AFPLICABLE TO 8416 ANG 18 DEVICES SEEMS SIMPLE IN THEORY, 

- PUT AS YOU WILL SEE, IT 100 HAS SOME SHOP TCOMINGS.e THE IDEA IS TO 
ALLOW A USER TC “SE T" WHATEVER SECTOR SIZE HE TESTRES FOR A’ GIVEN 
FILE. THE IDFA BEING THAT, SY USING LARGER SECTOR STZES, MUCH 
RETTER TRACK UTILIZATION PERCENTAGES CAN BF ORTAINFD, JUST AS THEY 
ARE bITH THE OLD CONVENTIONAL ACCESS METHODS. 


TKE USEF SPOCCIFIES THE VARIAULE SECTOR SIcE BY MEANS OF ANOTHER 
"7/ DO" PARAMETER, “VSECHNNNN%s UNLIKE MARY OTHER TRAM “CO” 
PARAMETERS, THIS OND MUST EXIST IN ALL wut STRFAMS WHICH USE THE 
FILE. FAILURE 19 CODE IV WIth RFSULT iw A "OMIT" OPEN ERROR. THIS 
IS WHERE THE PROBLEM BECINS, (CTHEORL TICALLY YOU CAN USE THE 
“ees ACCEPT" PAGAMETEH GN LEO STATEMENTS OF ALE SUSSEQUENT USERS OF 
THE FILE, FNSTTAU OF COIING A "VSFC® ON THEIR “GO. HOWEVER, THERE 
AVE THOSE OS/? SOF TAARC PERSONNEL wh CUNTEND THAT AN “ACCEFT™ MAY 
GO SCMF UNWANTED PROCESSING, AS TELL 4S wRANULISG THE VARIABLE 
SECTOR FROCESSING INDEPFROCENT CFE A “DU PARAMETERe ALSCy THERE IS 
NO WAY TO LOTH “ACCTPT® AND “EXTEND” A FILE, 8S THESE PARAMETERS 
ARE MUTUALLY CXCLUSTVEe) ALL GF THe YVSEC ST2ZING TAKES PLACE 
EXTERNALLY TO “IRAM, ANG IS COMMUNTCATE G TO CS/3 CNLY WHEN THE FILE 
1S ACCESSEDe COMPILERS ANG SYSTEM UTILITIES APE STILL UNLER THE 
ASSUMPTION THAY THE REAL SFCTO% SIZE IS «564 BYTES, ANDO THEY ENSURE 
THEIR MINIMUM SUFFER? STZES ACCORCIMGLY, 


SG, THE INITIAL PROBLEM WITH VSEC FILLS IS THAT COMPILED CODE IS 
NO LONSER "“SLOCK SIZE INDEPENDENT’ AS IN THE ORIGINAL IRAM 
IMPLEMENTATION. YOU CAN 8O LONGER VARY MI RAM RUFFER SIZES FOR THE 
SAME FItLEe WITHOUT SOME CONCERN FOR FHYSICAL SLOCK SIZES. IT IS 
VERY EASY, INWCG, TO ENG UP WITH A 512 FYTE BUFFER IN AN) RPG 
PPOGRAM bFHICH CAN Nul EVEN BEGIN TC HOLOG THE 2048 BYTE SECTOR SIZES 
ASSIGNED RY A USER WITH A “VSEC™ PARASC TER. THE SECOND PROBLEM 
RESULTS FROM THE FACT THAT ESSENTIALLY THE SAME RULES APPLY TO THE 
SECTOR, WHETHER IT [8S 250 AYTES CR SOME LASGER SIZE, SUCH AS 2048 
FYTES, IN LENGTH. RFMEMPER ThE 25@ i Y¥TE 8FCORP IN THE 256 BYTE 
SECTGR THAT YIFLOES A 766 KYTE MINIMUM BOFTER 7 TF I HAVE A 205C 
“eYTE COR LARGER) RECTRIC ANN A 2ON3 BYTE sore, 1 NEED 3 X 20488, OF 
61494 AYTES AS A MINIMUM BUFFER. YOU ROULS? FAVE TU MANUALLY INSURE 
THAT ALL FROSGPANS AKG UTILITIES HAD THEIR "BLOCK SIZES" OF “RECORD 
CONTAINS" SPECIFICATIONS COUEND LARGE EsGuSH TO HOLC ONE OF THESE 
6194 BYTE AREAS, NOT JUST 248. 


VSEC STTING MUST BE DONE BKITH GREAT CARF, AND ALL PRUGRAMS USINE 
THAT FILO MUST HAWE THEI “BUFFER SIT7ES" (RLOCKING FACTORS) 
ASSIGNED TO FE COMPATIPLE WITH THE VSEC, CNCE CHOSEN. IN 
CALCULATING VSEC, YOU MUST FIRST GETERMINE YOUR “SLOT SI7E". THIS 
IS EITHER YOUR RECORe SIZE, OR, 1F YOU ARE USTNG PCBTS, YOUR RECOeP 
SIZE PLUS GNF, THE TRICK THEN, TS 30 CHOSE A VSEC STZE THAT YS AN 
EXACT MULTIPLE OF “SLOT ST7E".s FOR EAAMPLE, IF wE HAVE Jol BYTE 
RECOKOS, WITH ROR TS, WE WOULD HAVE & SLOT SIZE OF 10156 LET°S SAY 
THAT WE CECIOC IN THIS CASE TO USE A VELC SIZE OF 1910, AS THIS 
BOULEL FE XACTLY #H#OL9 16 SLOTS. (NOTF THAT VS©C NEEL ACT CE A MULTIPLE 
OF Z€6!) THIS WOULD MEAN THAT: 
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ad ALL USER PROGRAMS MUST HAVE BLOCKING FACTORS TO GUARANTEE 
AT LFAST A 101C AYTE BUFFER. ; : 


- ALL DEVICE ASSIGAHMENT SETS FO? THAT FILE “UST JNCLUDE A 
“4/7 DO VSEC=IDIN” PARAMCTER SETTING. 


“NOW LETS ECIOE THAT YOU SUCBENLY DECIOE TO PERMANENTLY REMOVE 
THE &CR WITH & DATA UTILITY, BECAUSE YOU WANT TO RUN TKE FILE UNDER 
IMS/90~- RCB*S WERE SUPPOSEC TO bE “TRANSPAFENT™ TO USER CODE, THERE 
PRESENCE WAS SUPPOSED TO BE ELECTAPLE AT FILE CREATICN, WITH NO 
OTHER CONSIDERATIONS.» NOT SO WITh VSEC? GECAUSE, TAKING OFF THE RCE 
CHANGES YOUR SLOT SIZE, ANT NOW, THE ORAGINAL VSEC RESULTS IN A 
SITUATION WHERE THE RECORDS WILL SPAN SECTOFS.s THISe PER ORIGINAL 
SECTOR RULES, MEANS THAT YOU MUST HAVE SLUTFER SPACE FOR T¥O SEC TORS 
OR 2 XX 13039, OR IN OTHER WOPLS, 2420 BYTES.’ BUT MOST OF YOUR 
PRPOGRAMS WERE ORIGINALLY COMFILEG TO ENSURE GNLY ROOM FOR A 1610 
EYTE PUFFER. THE RESULT IS THAT YOU MUST FITHFR RECOMPILE THEM ALL 
BITH OILFFEPENT BLOCK SIZE SLLECTIONS, Ow SELECT A NEW VSEC SIZE AND 
CHANGE ALL YOUP JCL 10 ADHERE TO IT. 


A FINAL ASPECT OF VSEC WHICH 15 INTE NLVED 19 HELP PECTIFY THIS 
PROBLEM IS & VARIATION OF THE “VSEC™ STATEMENT, IN WHICH ALL JCL 
FOR A PARTICULAR FILE 15 COOLED WITH “VSECIYFS™" INSTEAD OF 
"VSECINNAN'. IN THIS CASL, MIRAM USES THE SLOT SIZE AND THE SUFFER 
SI2E OF THE PROGRAM THAT IS USING THE FILE, AND CALCULATES THE 
LAFGEST VSEC WHICH WILL FIT INTG THAT PUFFER. THIS KEEPS FUTURE JCL 
CHANGES 19 A MINIMUM, AUT MEANS THATS 


= YOU? LOAD PROGRAM CPOSSIBLY & DATA UTILITY) MUST HAVE A 
CARTFULLY CONSIDERED ELOCKSIZ7E, £0 AS TO YIELD THE VSEC 
SIZE THAT YOU DETERMINE TO BE THE MOST EFFICIENT, FOR A 
PARTICULAR SLOT SIZE, 


= ALL PROGRAMS WHICH ACCESS THE FILE MUST HAVE AT LEAST 
"VSECHYES™ (BUT COULT BE CODE YU WITH THE ABSOLUTE VSEC). 


=~ ALL USER PROLRAMS MUST THEW PE CCDED WITH BLOCK SIZES 
LARGE ENOUGH TO HOLD THE VSEC CALCULATED &Y THE LOAD 
PROGSSAM, 


= THOSE BLOCK STZES MUST RE CeOcEM SO THAT THEY O09 AOT 
RESULT IN A LARUEF SUFFER ST2E THAN THAT OF THE LCAC 
PROSRAM, OTHERWISE, THE CALCULATEL VSEC SIZE OF THAT 
USING PRIGRAM WOULT BE DIFTERENT THAN THE ONE CALCULATED 
FOR THE LOAD FROGRAM, RESULTING IN & "OMIT" ERROR. CT HE RE 


IS SUME SUESTION AS TC BHE THOR TRIS LAST POINT IS VALI 
a 


A USER SHOP Will HAVE TO (CETESMINE WHETHER “VSECINNNN” OR 
"VSECHYES" IS THE PEITER ME THOR GF IMPLEMENTING VARIABLE SECTOR 
SUPPORT ON THETR SELECTOR PISKS. UNFOCSTUNATELY, NEITHER COMES CLOSE 
TO FROVIDING THE TRUE LLOCKS Tée INCE PENDENT FLEXIGILITIES 
ORIGINALLY AFFORDED T0 A USER OF 286 SYTc SECTORS. 
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Se 


Sele 


MISCELLANOUS CONSICERATICNS. 


ANS 74 CO?0OL EXTEND. 


IN ALL PRIOR O83 RELEASES, THE CESIOGN bwAS SUCH THAT JCL 
SPECIFIED FILE PARAMETERS TOGK PRECEDENCE OF THOSE CODED IN THE 
PROGRAMs FOR EXAMPLE, IF A USER CONES “y,EYTEND™ ON AN LFO FOR A 
SFQUENTIAL OUTPUT FILE, THEN ITT EXTERNE D THE FILE. THIS IS NOT TRUE 
OF SEQUENTIAL MIRAMH GUTPUT. THERE ITS A CO2fL OPEN OPTION CALLED 
“OFEN EXTEND”. ONE BKOULD THINK THAT THIS WOULC ALLOW A USER TO 
REQUEST AN CYTENT, IN CASE ITT AS NOT KOCUESTED IN JCL. ONE WOULD 
ALSO TEIAK THAT IF YOU CUDFO “OPEN OUTPUT” AND USED A ™,,EXTEND” ON 
THE LFO THAT YOU wOUct ALSO GET EXTENCING. THE LATTER ITS NOT SOW 
FOS MIFAM OUTPUT FILTSs THE COPGL OPEN VEPrF HAS PRESE DENCE. THIS 
ROULC B3E UNDERSTANDABLE CXCEPT THAT IN THE SAME 74 COPOLs WHEN 
USING CONVENTIONAL "SAM" FILES, THE JCL OPTION STILL TAKES 
PRECEDENCE. THIS POINT CF CONFLICT HAS TEEN TAKEN UP BKITH SPERRY 
UNT VAC VIA A “RCOQUEST FOR CHANGE” SUBMITTED AT THE FALL 6&5 AUUA 
CONFE PENCE. 


DOCUMENT: TUYAF 29 ROVs2.0 SECTICN:5S.1. 
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